In conventional PSTN networks, caller ID information can be communicated to a PSTN phone with caller ID display capabilities using in-band signaling. The caller ID information typically includes the directory number from which the caller is calling. Call waiting is a feature that notifies a called party during a call that a call is waiting to be answered and that allows the called party to switch between the active and waiting calls.
In call waiting scenarios, it is desirable to display caller ID information to the called party so that the called party can determine whether to switch to the waiting call. As described above, caller ID information can be communicated to a PSTN phone using in-band signaling, and the called party can decide whether or not to switch. The call waiting indication is typically communicated to the PSTN phone or user by playing a tone to the user over the media connection for the existing call. When the user hears the tone and determines to switch to the waiting call, the user communicates a hook flash to the switch, and the switch replaces the active call with the waiting call. The user can toggle between the active and waiting calls by sending hook flashes to the switch.
In packet telephony networks, it is desirable to provide such caller ID, call waiting, and toggling capabilities. In one conventional implementation, a packet telephony call can be established between first and second phones using out-of-band signaling, such as SIP. When a third phone attempts to call the first phone, the first phone or user can be alerted of the waiting call using an in-band tone, as in the conventional PSTN case. However, it is believed that there is currently no method for communicating caller ID information regarding the waiting call to the first phone, when the first phone is a SIP termination. In addition, if the user of the first phone decides to switch to the waiting call, new media connections between the first phone and a media gateway must be established for the waiting call. Toggling between the active and waiting calls also requires repeated establishment of new media connections between the first phone and the media gateway.
FIG. 1 is a call flow diagram illustrating one conventional solution for toggling between active and waiting calls using SIP and multiple real time transmission protocol (RTP) streams between a SIP phone and a media gateway. Referring to FIG. 1, a first SIP phone P1 100 initially calls a second phone P2 102. The call is established via media gateway controller/media gateway (MGC/MG) 106. A third phone P3 104 attempts to call P1 100 while the first call is in progress.
In line 1 of the message flow diagram, phone P1 100 sends a SIP Invite message to MGC/MG 106 inviting phone P2 102 to a media session. In line 2 of the message flow diagram, MGC/MG 106 sends an Invite message to phone P2 102 inviting phone P2 102 to join the session with phone P1 100. In line 3 of the message flow diagram, phone P2 102 accepts the invitation and forwards a 100 Trying message to MGC/MG 106. In line 3 of the message flow diagram, MGC/MG 106 sends an INVITE message to phone P2 102. In line 4 of the message flow diagram, phone P2 102 sends a 100 Trying message to MGC/MG 106. In line 5 of the message flow diagram, phone P2 102 sends a 200 OK message to MGC/MG 106. In line 6 of the message flow diagram, MGC/MG 106 sends an ACK message to phone P2 102 acknowledging the 200 OK. In line 7 of the message flow diagram, MGC/MG 106 sends a 200 OK message to phone P1 100 indicating that the P2 102 accepted the invitation. In line 8 of the message flow diagram, phone P1 100 sends an ACK message to MGC/MG 106 acknowledging the 200 OK. After line 8 of the message flow diagram, in line 9, a first RTP session, RTP1, is established between phone P1 100 and MGC/MG 106 and a second RTP session, RTP2, is established between MGC/MG 106 and phone P2 102.
In line 10 of the message flow diagram, phone P3 104 calls phone P1 100, and an INVITE message is sent to MGC/MG 106. In line 11 of the message flow diagram, MGC/MG 106 sends a call waiting tone over the RTP stream RTP1 to phone P1 100 indicating that a call is waiting. In line 12 of the message flow diagram, MGC/MG 106 sends an INVITE message to phone P1 100 for the incoming call from phone P3 104. In line 13 of the message flow diagram, phone P1 100 sends a 180 Ringing message to MGC/MG 106 informing MGC/MG 106 that P1 is now ringing. Using conventional SIP methods, however, there is no way for MGC/MG 106 to guarantee that the caller ID information is provided phone P1 100. Accordingly, the user of phone P1 100 may have to determine whether or not to switch without knowing who is calling.
In line 14 of the message flow diagram, phone P1 100 sends a hook flash over the RTP stream to MGC/MG 106. In line 15 of the message flow diagram, phone P1 100 sends an INVITE message to MGC/MG 106 to put phone P2 102 on hold. In line 16 of the message flow diagram, MGC/MG 106 sends a 200 OK message to phone P1 100. In line 17 of the message flow diagram, phone P1 100 sends an acknowledgment message to MGC/MG 106 for the 200 OK message. In line 18 of the message flow diagram, phone P1 100 sends a 200 OK message to MGC/MG 106. In line 19 of the message flow diagram, MGC/MG 106 sends an acknowledgment message to phone P1 100. In line 20 of the message flow diagram, MGC/MG 106 sends a 200 OK message to phone P3 104. In line 21 of the message flow diagram phone P3 104 sends an acknowledgement message to MGC/MG 106. In line 22 of the message flow diagram, third and fourth RTP streams, RTP3 and RTP4, are established to connect phone P1 100 to MGC/MG 106 and phone P2 102 to MGC/MG 106. The third and fourth RTP streams require separate resources on the media gateway of MGC/MG 106 and therefore reduce bandwidth available for other calls. In addition, separate Invite messaging is required for each waiting call. The problem is increased if multiple parties desire to connect with a single party, as in a multi-line conference.
Accordingly, in light of these difficulties associated with providing call waiting, caller ID and toggling between active and waiting calls, there exists a need for methods, systems, and computer program products for providing call waiting and caller ID and for toggling between active and waiting calls using SIP.